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Abstract 


This document defines a new RTP Control Protocol (RTCP) Packet Type 
and an RTCP Extended Report (XR) Block Type to be used for achieving 
Inter-Destination Media Synchronization (IDMS).  IDMS is the process 
of synchronizing playout across multiple media receivers. Using the 
RTCP XR IDMS Report Block defined in this document, media playout 
information from participants in a synchronization group can be 
collected. Based on the collected information, an RTCP IDMS Settings 
Packet can then be sent to distribute a common target playout point 
to which all the distributed receivers, sharing a media experience, 
can synchronize. 


Typical use cases in which IDMS is useful are social TV, shared 
service control (i.e., applications where two or more geographically 
Separated users are watching a media stream together), distance 
learning, networked video walls, networked loudspeakers, etc. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7272. 
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publication of this document. Please review these documents 
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Les 


T: 


2. 


Lio 


Introduction 


IDMS refers to the playout of media streams at two or more 
geographically distributed locations in a time-synchronized manner. 
It can be applied to both unicast and multicast media streams and can 
be applied to any type and/or combination of streaming media, such as 
audio, video, and text (subtitles). [Ishibashi2006] and 
[Boronat2009] provide an overview of technologies and algorithms for 
IDMS. 


Inter-Destination Media Synchronization (IDMS) requires the exchange 
of information on media arrival and presentation times among 
participants in an IDMS session. It may also require signaling for 
the initiation and maintenance of IDMS sessions and groups of 
receivers. 


The presented RTCP specification for IDMS is independent of the 
synchronization algorithm employed, which is out of scope of this 
document. 


1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Rationale 
1. Applicability of RTCP to IDMS 


Currently, a large share of real-time applications make use of RTP 
and RTCP [RFC3550]. RTP provides end-to-end network transport 
functions suitable for applications requiring real-time data 
transport, such as audio, video, or data, over multicast or unicast 
network services. The timestamps, sequence numbers, and payload 
(content) type identification mechanisms provided by RTP packets are 
very useful for reconstructing the original media timing and the 
original order of packets and for detecting packet loss at the 
receiver. 


The data transport is augmented by a control protocol (RICP) to allow 
monitoring of the data delivery in a manner that is scalable to large 
groups and to provide minimal control and identification 
functionality.  RTP receivers and senders provide reception quality 
feedback by sending out RTCP receiver report (RR) and sender report 
(SR) packets [RFC3550], respectively, which may be augmented by 
extended report (XR) blocks [RFC3611]. 
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IDMS involves the collection, summarization, and distribution of RTP 
packet arrival and presentation times. As information on RTP packet 
arrival times and presentation times can be considered reception 
quality feedback information, RTCP is well suited for carrying out 
IDMS. 


2.2.  IDMS and ETSI 


A first version of IDMS for use with RTP/RTCP was standardized by 
ETSI Telecommunications and Internet converged Services and Protocols 
for Advanced Networking (TISPAN) in [TS183063], resulting in an IANA 
registration for an RTCP XR Block Type. This work was then brought 
as input to the IETF AVTCORE WG for further standardization, 
leveraging the RTP/RICP expertise present in the AVTCORE WG. This 
document is the result of that effort. 


Although the IDMS protocol described in this document has evolved 
significantly from the version that was originally specified by ETSI 
TISPAN, it is still backwards compatible with the ETSI version. As 
such, it had been decided in ETSI to update the TS 183 063 document 
to reference this document as the normative specification of IDMS. 
This update can be found in newer versions of TS 183 063 (i.e., 
versions higher than 3.5.2). In accordance, this document proposes 
to update the IANA registration for the RTCP XR IDMS Report Block to 
point to this document. Finally, this document proposes an IANA 
registry for Synchronization Packet Sender Type (SPST) values, 
allowing the registration of extensions to this document. 


3. Inter-Destination Media Synchronization (IDMS) Use Cases 


There is a large number of use cases in which IDMS might be useful. 
This section will highlight some of them. It should be noted that 
this section is in no way meant to be exhaustive. 


A first usage scenario for IDMS is social TV. Social TV is the 
combination of media content consumption by two or more users at 
different devices and locations combined with real-time communication 
between those users. An example of social TV is when two or more 
users are watching the same television broadcast at different devices 
and locations, while communicating with each other using text, audio, 
and/or video. A skew in their media playout processes can have 
adverse effects on their experience. A well-known use case here is 
one friend experiencing a goal in a football match well before or 
after another friend(s). 


Another potential use case for IDMS is a networked video wall. A 
video wall consists of multiple computer monitors, video projectors, 
or television sets tiled together contiguously or overlapped in order 
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to form one large screen. Each of the screens reproduces a portion 
of the larger picture. In some implementations, each screen may be 
individually connected to the network and receive its portion of the 
overall image from a network-connected video server or video scaler. 
Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or 
potentially faster. If the refresh is not synchronized, the effect 
of multiple screens acting as one is broken, with users noticing 
tearing effects and no longer perceiving a single image. 


A third usage scenario is that of networked loudspeakers in which two 
or more speakers are connected to the network individually. Such 
Situations can, for example, be found in large conference rooms, 
legislative chambers, classrooms (especially those supporting 
distance learning), and other large-scale environments such as 
stadiums. Since humans are more sensitive to differences in audio 
delay compared to video delay, this use case needs even more accuracy 
than the video wall use case. Depending on the exact application, 
the need for accuracy can then be in the range of microseconds. 


4. Overview of IDMS Operation 


This section provides a brief example of how the RTCP functionality 
is used for achieving IDMS. The section is tutorial in nature and 
does not contain any normative statements. 


Atrce's- au 4e EMI COMA eec 3049 xo Bob's 
TV (Sync Client) (Sync Server) Laptop (Sync Client) 


Media Session | 
|< >| | 
| Invite (URL, SyncGroupId) 
| 
| 


| ------------------------------------------------- > 
| | Media Session Setup 

| < > 
| Call Setup | 
|< >| 
| | | 
| RTP Packets | RTP Packets | 
<---------------------- | ------------------------- > 

RR + XR IDMS Report | 

| ---------------------- > | RR + XR IDMS Report | 
| | <------------------------- | 
| RTCP IDMS Settings | RTCP IDMS Settings | 
E |------------------------- d 


Figure 1: Example of a Typical IDMS Session 
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Alice is watching TV in her living room. At some point, she sees 
that Bob's favorite team is playing football. She sends him an 
invite to watch the program together. Embedded in the invitation is 
the link to the media server and a unique sync-group identifier. 


Bob, who is also at home, receives the invite on his laptop. He 
accepts Alice's invitation, and the RTP client on his laptop sets up 
a session with the media server. A Voice over IP (VoIP) connection 
to Alice's IV is also set up, so that Alice and Bob can talk while 
watching the game together. 


As is common with RTP, both the RTP client in Alice's TV as well as 
the one in Bob's laptop send periodic RTCP RRs to the media server. 
However, in order to make sure Alice and Bob see the events in the 
football game at the same time, their clients also periodically send 
an RTCP XR IDMS Report Block to the Sync Server function of the media 
server. Included in the RTCP XR IDMS Report Blocks are timestamps on 
when both Alice and Bob received (and, optionally, when they played 
out) a particular RTP packet. 


The Sync Server function in the media server calculates a reference 
client from the received RTCP XR IDMS Report Blocks (e.g., by 
selecting the most lagged client as the reference for IDMS). It then 
sends an RTCP IDMS Settings Packet containing the playout information 
of this reference client to the sync clients of both Alice and Bob. 


In this case, Bob's connection has the longest delay and the 
reference client, therefore, includes a delay similar to the one 
experienced by Bob. Upon reception of this information, Alice’s RTP 
client can choose what to do with this information. In this case, it 
decreases its playout rate temporarily until the playout time matches 
with the reference client playout (and, thus, matches Bob's playout). 
Another option for Alice's TV would be to simply pause playback until 
it catches up. The exact implementation of the synchronization 
algorithm is up to the client. 


Upon reception of the RTCP IDMS Settings Packet, Bob's client does 
not have to do anything since it is already synchronized to the 
reference client (since it is based on Bob's delay). Note that other 
synchronization algorithms may introduce even more delay than the one 
experienced by the most delayed client, e.g., to account for delay 
variations, for new clients joining an existing synchronization 
group, etc. 


For this functionality to work correctly, it is necessary that the 
wallclocks of the receivers are synchronized with each other. While 
Alice and Bob both report when they receive, and optionally when they 


van Brandenburg, et al. Standards Track [Page 6] 


REC 7272 RTCP for IDMS June 2014 


playout, certain RTP packets, in order to correlate their reports to 
each other, it is necessary that their wallclocks are synchronized. 


5. Architecture for Inter-Destination Media Synchronization 


The architecture for IDMS, which is based on a sync-maestro 
architecture [Boronat2009], is diagrammed below. In this particular 
case, the Synchronization Client (SC) and Media Synchronization 
Application Server (MSAS) entities are shown as additional 
functionality for the RTP receiver and sender, respectively. 


4----------------------- + 4----------------------- + 
| | sR+ | | 
| RTP Receiver | RTCP | RTP Sender | 
| | IDMS | | 
| 4----------------- * «----- | 4----------------- + | 
| | | | 
| | Synchronization | | | | Media | | 
| | Client E | [| Synchronization | | 
| | (SC) | | | | Application Lo 
lt | | | | Server pol 
RR+XR (MSAS) 
| e93 | 
| o0----------------- + | | +----------------- + | 
| | | | 
4----------------------- + +----------------------- + 


Figure 2: IDMS Architecture Diagram 
5.1. Media Synchronization Application Server (MSAS) 


An MSAS collects RTP packet arrival times and presentation times from 
one or more SCs in a synchronization group by receiving RTCP XR IDMS 
reports. The MSAS summarizes and distributes this information to the 
SCs in the synchronization group as synchronization settings via the 
RTCP IDMS Settings Packet messages, e.g., by determining the SC with 
the most lagged playout and using its reported RTP packet arrival 
time and presentation time as a summary. 


It should be noted that while the diagram above shows the MSAS as 
part of the RTP sender, this is not necessary. For example, an MSAS 
might also be implemented as an independent function in the network 
or in a master/slave type of architecture where one of the SC devices 
also acts as an MSAS. Wherever the MSAS is implemented, it is 
important that the MSAS has access to the RTP stream to which the XR 
reports apply, so that it is able to correlate the RTCP XR IDMS 
reports coming from different SCs. 
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5 


25. 


2:3. 


Synchronization Client (SC) 


An SC reports on RTP packet arrival times and presentation times of a 
media stream. It can receive IDMS Settings Packets containing 
summaries of such information and use that to adjust its playout 
buffer. The SC sends RTCP XR IDMS reports to the MSAS. 


Communication between MSAS and SCs 


Two different message types are used for the communication between 

MSAS and SCs. For the SC->MSAS message containing the arrival and 

playout information of a particular client, an RTCP XR IDMS Report 

Block is used (see Section 6). For the MSAS->SC message containing 
the synchronization settings instructions, a new RTCP IDMS Settings 
Packet is defined (see Section 7). 


RTCP XR IDMS Report Block 


This section specifies a new RTCP XR Block Type, the RTCP XR IDMS 
Report Block, for reporting IDMS information to an MSAS. In 
particular, it is used to provide feedback information on arrival 
times and presentation times of RTP packets. Its definition is based 
on [RFC3550] and [RFC3611]. 


In most cases, a single RTP receiver will only be part of a single 
IDMS session, i.e., it will report on arrival and presentation times 
of RTP packets from a single RTP stream in a certain synchronization 
group. In some cases, however, an RTP receiver may be a member of 
multiple synchronization groups for the same RTP stream, e.g., 
watching a single television program simultaneously with different 
groups. In even further cases, a receiver may wish to synchronize 
different RTP streams at the same time, either as part of the same 
synchronization group or as part of multiple synchronization groups. 
These are all valid scenarios for IDMS and will require multiple 
reports by an SC. 


This document does not define new rules for when to send RTCP 
reports, but uses the existing rules specified in [RFC3550] for 
sending RTCP reports. When the RTCP reporting timer allows an SC to 
send an IDMS report, the SC SHOULD report on an RTP packet received 
during the period since the last RTCP XR IDMS Report Block was sent. 
Because of RTP timestamp rollover, there is ambiguity in mapping RTP 
timestamps to NTP timestamps. The recommendation to report on recent 
RTP packets serves to manage this ambiguity. For more details on 
which packet to report on, see below under "Packet Received RTP 
timestamp". 
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0 1 2 3 
0:.2-34 56 7 89 0.12 3 4 5-6 7.8 9:0 1-2 3-4: 956 7 8 9:01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| BT=12 | SPST |Resrv|P| block length=7 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| PT | Resrv | 


O S E E A A E  -t 
| Media Stream Correlation Identifier 

a e a A G E E A E E E 
| SSRC of media source 

a a atta a E E 
| Packet Received NIP timestamp, most significant word | 
*-——R——B-— LL ta E A E 
| Packet Received NIP timestamp, least significant word | 
Pat RHF tata tata tata E O 
| Packet Received RTP timestamp 

a atta tanta tanta tata ta S tata tata MM O 
| Packet Presented NTP timestamp 

a a tata a tata tata A tata À M £t - 


The RTCP XR IDMS Report Block consists of 8 32-bit words, with the 
following fields: 


Block Type (BT): 8 bits. It identifies the block format. Its value 
is set to 12. 


Synchronization Packet Sender Type (SPST): 4 bits. This field 
identifies the role of the packet sender for this specific Extended 
Report. It can have the following values, as enumerated in a 
registry maintained by IANA (see Section 13.4): 


SPST=0 Reserved for future use. 
SPST=1 The packet sender is an SC. It uses this XR to report 
synchronization status information. Timestamps relate to the SC 
input. 
SPST=2-4 Values defined by ETSI TISPAN (see [TS183063]). 
SPST=5-15 Unassigned. 
Reserved bits (Resrv): 3 bits. These bits are reserved for future 
definition. In the absence of such a definition, the bits in this 


field MUST be set to zero at transmission and MUST be ignored by the 
receiver. 
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Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the 
Packet Presented NTP timestamp field contains a value, 0 if it is 
empty. If this flag is set to 0, then the Packet Presented NTP 
timestamp SHALL be ignored by the receiver. 


Block Length: 16 bits. This field indicates the length of the block 
in 32-bit words minus one and is set to 7, as this RTCP XR IDMS Block 
Report has a fixed length. 


Payload Type (PT): 7 bits. This field identifies the format of the 
media payload, according to [RFC3551]. This is the payload type of 
the RTP packet reported upon. The PT field is needed in the case 
where the MSAS is neither the media server nor a receiver of the 
media stream, i.e., it is implemented as a third-party entity. In 
such cases, the MSAS needs the PT to determine the rate of 
advancement of the timestamps of the RTP media stream to be able to 
relate reports from different SCs on different RIP timestamp values. 


Reserved bits (Resrv): 25 bits. These bits are reserved for future 
use and SHALL be set to 0 at transmission and MUST be ignored by the 
receiver. 


Media Stream Correlation Identifier: 32 bits. This identifier is 
used to correlate synchronized media streams. The value 0 (all bits 
are set "0") indicates that this field is empty. The value 2%32-1 
(all bits are set "1") is reserved for future use. If the RTCP 
Packet Sender is an SC (SPST=1), then the Media Stream Correlation 
Identifier field contains the Synchronization Group Identifier 
(SyncGroupId) to which the report applies. 


Synchronization Source (SSRC): 32 bits. The SSRC of the media source 
is set to the value of the SSRC identifier carried in the RTP header 
[RFC3550] of the RTP packet to which the XR IDMS relates. 


Packet Received NIP timestamp: 64 bits. This timestamp reflects the 
wallclock time at the moment of arrival of the first octet of the RTP 
packet to which the XR IDMS relates. It is formatted based on the 
NTP timestamp format as specified in [RFC5905]. See Section 8 for 
more information on how this field is used. 


Packet Received RTP timestamp: 32 bits. This timestamp has the value 
of the RTP timestamp carried in the RTP header [RFC3550] of the RTP 
packet to which the XR IDMS relates. Several consecutive RTP packets 
will have equal timestamps if they are (logically) generated at once, 
e.g., belong to the same video frame. It may well be the case that 
one receiver reports on the first RTP packet that has a certain RTP 
timestamp, and a second receiver reports on the last RTP packet that 
has that same RTP timestamp. This would lead to an error in the 
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synchronization algorithm due to the faulty interpretation of 
considering both reports to be on the same RTP packet. When 
reporting on an RTP packet, which is one of several consecutive RTP 
packets having equal timestamps, an SC SHOULD report on the RTP 
packet it received with the lowest sequence number. Note that 
‘lowest sequence number’ here is meant to be the first in the 
sequence of RTP packets just received, not from an earlier time 
before the last wrap around of RIP timestamps (unless this wrap 
around occurs during the sequence with equal RIP timestamps). 


Packet Presented NTP timestamp: 32 bits. This timestamp reflects the 
wallclock time at the moment the rendered media unit (e.g., video 
frame or audio sample) contained in the first byte of the associated 
RTP packet is presented to the user. It is based on the time format 
used by NTP and consists of the least significant 16 bits of the NTP 
seconds part and the most significant 16 bits of the NTP fractional 
second part. If no Packet Presented NIP timestamp is available, this 
field SHALL be set to 0 and be considered empty, and the Packet 
Presented NTP timestamp flag (P) SHALL be set to 0. With regards to 
NTP epoch and rollover, the value of the Packet Presented NTP 
timestamp is considered to always be greater than the Packet Received 
NTP timestamp and to be within 2^16 seconds of it. Presented in this 
context means the moment the data is played out to the user of the 
system, i.e., sound played out through speakers, video images being 
displayed on some display, etc. The accuracy resulting from the 
synchronization algorithm will only be as good as the accuracy with 
which the SCs can determine the delay between receiving packets and 
presenting them to the end user. If no presentation timestamps are 
reported by SCs, the ability to accurately synchronize playout may be 
limited. 


RTCP Packet Type for IDMS (IDMS Settings Packet) 


This section specifies the RTCP packet type for indicating 
synchronization settings instructions to the receivers of the RTP 
media stream. Its definition is based on [RFC3550]. Synchronization 
settings take the form of a report referencing a real or hypothetical 
RTP packet selected or contrived by the MSAS. 
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d—R———.—.—.-——-—R-—R-—R—R-—R-—R—R— RM 4 4 4 + + + ++ +++ Y 

|v=2|P| Resrv | PT=211 | length 

+ hh + Rd dd de dd dd dd dd 4 4 4 4 4 + + + +++ ++ +++ 
| SSRC of packet sender 
FSPStStetaetatatatatatatatatatatatatatatatatatatatatatataetatetetet 
| SSRC of media source 

dh + RR dd de e e de de de dd dd de 4 4 4 4 + + +++ ++ +++ 
| Media Stream Correlation Identifier 

+ hh RO A dd de de e de de de dd dd de 4 4 4 4 + + + +++ ++ +++ 
| Packet Received NIP timestamp, most significant word | 
+ hh A A A de e e e e e dd dd de de de dd 4 + + + + + + + +++ 
| Packet Received NIP timestamp, least significant word | 
dh hh Rd dd de dd e dd dd de de 4 4 4 4 + + + +++ ++ +++ 
| Packet Received RTP timestamp 

dh hd Rd de de de e e de de dd dd de 4 4 4 4 + + + ++ +++ +++ 
| Packet Presented NTP timestamp, most significant word | 
+ hh A A dd e e e e e de dd de de de dd 4 4 dh + + + + + + +++ 
| Packet Presented NIP timestamp, least significant word | 
dh + RO A RO dd e e e e dd dd de de de 4 4 4 + + + + + ++ +++ 


The first 64 bits form the header of the RTCP packet type, as defined 
in [RFC3550]. The SSRC of the packet sender identifies the sender of 
the specific RICP packet. 


The RTCP IDMS Settings Packet consists of 7 32-bit words, with the 
following fields: 


PT: 211, as registered by IANA. 


SSRC: 32 bits. The SSRC of the media source is set to the value of 
the SSRC identifier of the media source carried in the RTP header 
[RFC3550] of the RTP packet to which the RTCP IDMS Settings Packet 
relates. 


Media Stream Correlation Identifier: 32 bits. This identifier is 
used to correlate synchronized media streams. The value 0 (all bits 
are set "0") indicates that this field is empty. The value 2^32-1 
(all bits are set "1") is reserved for future use. The Media Stream 
Correlation Identifier contains the SyncGroupld of the group to which 
this packet is sent. 


Packet Received NTP timestamp: 64 bits. This timestamp reflects the 
wallclock time at the reference client at the moment it received the 
first octet of the RTP packet to which this packet relates. It can 
be used by the synchronization algorithm on the receiving SC to 

adjust its playout timing in order to achieve synchronization, e.g., 
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to set the required playout delay. The timestamp is formatted based 
on the NIP timestamp format as specified in [RFC5905]. See Section 8 
for more information on how this field is used. Because RTP 
timestamps do wrap around, the sender of this packet MUST use recent 
values, i.e., choose NIP timestamps that reflect current time and not 
too far in the future or in the past so as to create ambiguity with 
regards to RTP timestamp wrap around. 


Packet Received RIP timestamp: 32 bits. This timestamp has the value 
of the RTP timestamp carried in the RTP header [RFC3550] of the RTP 
packet to which the XR IDMS relates. This SHOULD relate to the first 
arriving RTP packet containing this particular RIP timestamp, in case 
multiple consecutive RTP packets contain the same RIP timestamp. 


Packet Presented NIP timestamp: 64 bits. This timestamp reflects the 
wallclock time at the reference client at the moment it presented the 
rendered media unit (e.g., video frame or audio sample) contained in 
the first octet of the associated RTP packet to the user. The 
timestamp is formatted based on the NTP timestamp format as specified 
in [RFC5905]. If no Packet Presented NTP timestamp is available, 
this field SHALL be set to 0 and be considered empty. This field MAY 
be left empty if none or only one of the receivers reported on 
presentation timestamps. Presented here means the moment the data is 
played out to the user of the system. 


In some use cases (e.g., phased array transducers), the level of 
control an MSAS might need to have over the exact moment of playout 
is so precise that a 32-bit Presented timestamp will not suffice. 

For this reason, this RTCP packet type for IDMS includes a 64-bit 
Presented Timestamp field. Since an MSAS will in practice always add 
some extra delay to the delay reported by the most lagged receiver 
(to account for packet jitter), it suffices for the RTCP XR IDMS 
Report Block with which the SCs report on their playout to have a 
32-bit Presented Timestamp field. 


Timing and NIP Considerations 


To achieve IDMS, the different receivers involved need synchronized 
wallclocks as a common timeline for synchronization. This 
synchronized clock is used for reporting the Packet Received NTP 
timestamp and the Packet Presented NTP timestamp, and for 
interpretation of these fields in received IDMS Settings Packets. 
Depending on the synchronization accuracy required, different clock 
synchronization methods can be used. For social TV, synchronization 
accuracy should be achieved on the order of hundreds of milliseconds. 
In that case, correct use of NTP on receivers will in most situations 
achieve the required accuracy. As a guideline, to deal with clock 
drift of receivers, receivers should synchronize their clocks at the 
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beginning of a synchronized session. In case of high required 
accuracy, the synchronized clocks of different receivers should not 
drift beyond the accuracy required for the synchronization mechanism. 
In practice, this can mean that receivers need to synchronize their 
clocks repeatedly during a synchronization session. 


Because of the stringent synchronization requirements for achieving 
good audio quality in some use cases, a high accuracy will be needed. 
In this case, use of the global NTP system may not be sufficient. 

For improved accuracy, a local NTP server could be set up, or some 
other more accurate clock synchronization mechanism can be used, such 
as GPS time or the Precision Time Protocol [IEEE1588-2008]. 


[RFC7273] defines a set of Session Description Protocol (SDP) 
parameters for signaling the clock synchronization source or sources 
available to and used by the individual receivers.  SCs MAY use 
[RFC7273] to indicate their clock synchronization source or sources 
in use and available. Using these parameters, an SC can indicate 
which synchronization source is being used at the moment. An SC can 
also indicate any other synchronization sources available to it. 
This allows multiple SCs in an IDMS session to use the same or a 
similar clock source for their session. 


Applications performing IDMS may or may not be able to choose a 
synchronization method for the system clock because this may be a 
system-wide setting that the application cannot change. How 
applications deal with this is up to the implementation. The 
application might control the system clock, or it might use a 
Separate application clock or even a separate IDMS session clock. It 
might also report on the system clock and the synchronization method 
used, without being able to change it. 


[RFC7164] presents some guidelines on how RTP senders and receivers 
should deal with leap seconds. When relying on NTP for clock 
synchronization, IDMS is particularly sensitive to 
leap-second-induced timing discrepancies. It is RECOMMENDED to take 
the guidelines specified in [RFC7164] into account when implementing 
IDMS. 


On the Use of Presentation Timestamps 


A receiver can report on different timing events, i.e., on packet 
arrival times and on playout or presentation times. A receiver SHALL 
report on arrival times and a receiver MAY report on playout times. 
RTP packet arrival times are relatively easy to report on. Normally, 
the processing and playout of the same media stream by different 
receivers will take roughly the same amount of time.  Synchronizing 
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on packet arrival times may lead to some accuracy loss, but it will 
be adequate for many applications, such as social TV. 


Also, if the receivers are in some way controlled, e.g., having the 
same buffer settings and decoding and rendering times, high accuracy 
can be achieved. However, if all receivers in a synchronization 
session have the ability to report on and, thus, synchronize on 
actual presentation times, this will be more accurate. It is up to 
the applications and implementations of this RTCP extension whether 
to implement and use presentation timestamps. 


SDP Signaling for RTCP IDMS Settings Packet 


The SDP attribute rtcp-idms is used to signal the use of the RTCP 
IDMS Settings Packet and the associated RTCP XR IDMS Report Block. 

It is also used to carry an identifier of the synchronization group 
to which clients belong or will belong. The SDP attribute is used as 
a media-level attribute during session setup. This means that in 
case of multiple related streams, IDMS is performed on one of them. 
The other streams will be synchronized to this reference or master 
stream using existing inter-stream synchronization (such as lip-sync) 
Solutions, i.e., using sender reports based on a common clock source. 
Basic guidelines for choosing the media stream for IDMS is to choose 
audio above video, as humans are most sensitive to degradation in 
audio synchronization. When using multi-description or multi-view 
codecs, the IDMS control should be performed on the base layer. 


This SDP attribute is defined as follows, using Augmented Backus-Naur 
Form [RFC5234]. 


rtcp-idms = "a=" "rtcp-idms" ":" sync-grp CRLF 

sync-grp - "sync-group-" SyncGroupId 

SyncGroupId = 1*10DIGIT ; Decimal value from 0 through 4294967294 
DIGIT = $x30-39 

SyncGroupId is a 32-bit unsigned integer and represented in decimal. 
SyncGroupId identifies a group of SCs for IDMS. The value 
SyncGroupId-0 represents an empty SyncGroupId. The value 4294967295 
(2^32-1) is reserved for future use. For a description on the value 
of SyncGroupId to include, see Section 11. 


The following is an example of the SDP attribute for IDMS. 


a-rtcp-idms:sync-group-42 
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SDP Rules 
1. Offer/Answer Rules 


The SDP usage for IDMS follows the rules defined in [RFC4566] and 
Section 5 of [RFC3611] on SDP signaling with the exception of what is 
stated here. The IDMS usage of RTCP is a loosely coupled 
collaborative attribute, in the sense that receivers send their 
status information and, in response, the MSAS asynchronously sends 
synchronization setting instructions. The rtcp-idms attribute, thus, 
indicates the ability to send and receive indicated RTCP messages. 
This section defines how this SDP attribute should be used with 
regard to an offer/answer context. 


It is expected that, in most cases, the rtcp-idms attribute will be 
used in an offer/answer context where receivers will have 
predetermined, through some means outside the scope of this document, 
a SyncGroupId before the media session is set up. However, A sender 
that assigns a SyncGroupId is also supported for cases, for example, 
where the MSAS contains group management functionality and is 
co-located with or otherwise communicates with the sender. Thus, 
both senders and receivers can insert the attribute and the 
SyncGroupId. Furthermore, the attribute is allowed to be inserted 
for more than one media stream, allowing an SC to become part of 
multiple synchronization groups simultaneously. This effectively 
couples two (or more) synchronization groups to each other. If the 
rtcp-idms attribute is inserted more than once for a particular media 
session, each SyncGroupId SHALL only be inserted once. 


In order to join an IDMS session, the receiver (the SC) inserts the 
rtcp-idms attribute as a media-level attribute in the SDP offer. 

This SDP offer can be an initial offer if the media session is 
starting as a synchronized session. The SDP offer can also be an 
update to an existing media session, converting the session to an 
IDMS session. If the receiver has a predetermined SyncGroupId value, 
it SHOULD use this value for setting the SyncGroupId parameter in the 
rtcp-idms attribute. If the receiver does not know the SyncGroupId 
to be used, it MAY leave the SyncGroupId parameter empty by setting 
its value to 0. 


The sender SHALL include the rtcp-idms attribute in its answer. If 
the value of the SyncGroupId parameter in the offer is not empty (not 
equal to 0), the sender SHOULD NOT change the SyncGroupId in its 
answer. If the SyncGroupId is empty, the sender SHALL include the 
proper SyncGroupId in its answer. If the sender receives an offer 
with the value of the SyncGroupId parameter set to 0, and cannot 
determine the proper SyncGroupId, it SHALL remove the attribute from 
its answer. 
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A sender receiving an SDP offer without the rtcp-idms attribute can 
also decide that IDMS is applicable to that media session. In such a 
case, the sender MAY insert the rtcp-idms attribute, including a non- 
empty SyncGroupId, as part of its answer. 


A receiver receiving an rtcp-idms attribute as part of the SDP answer 
from a sender SHALL start sending RTCP XR IDMS reports (following all 
the normal RTCP rules for sending RTCP XR IDMS Report Blocks) and 
SHALL be ready to start receiving IDMS Settings. As usual, if a 
receiver does not support the attribute (e.g., in case of an MSAS- 
inserted IDMS attribute), it SHALL ignore the attribute. 


Different updates are applicable to such an IDMS session. Updates 
can be sent omitting the rtcp-idms attribute, thereby ending 
involvement in the synchronization session. Updates can also be sent 
including the rtcp-idms attribute, but with a different SyncGroupld. 
This indicates a switch in the synchronization group. 


.2. Declarative Cases 


In certain situations, there is no offer/answer context, but only a 
declarative modus. In this case, the MSAS just inserts the rtcp-idms 
attribute and a valid SyncGroupId. Any receiver receiving the rtcp- 
idms attribute in such a declarative Case SHALL start sending RTCP XR 
IDMS Report Blocks and SHALL be ready to start receiving RTCP IDMS 
Settings Packets. 


Security Considerations 


The security considerations described in [RFC3611] apply to this 
document as well. 


The RTCP XR IDMS Report Block defined in this document is used to 
collect, summarize, and distribute information on packet reception 
and playout times of streaming media. The information may be used to 
orchestrate the media playout at multiple devices. 


Errors in the information, either accidental or malicious, may lead 
to undesired behavior. For example, if one device erroneously or 
maliciously reports a two-hour delayed playout, then another device 
in the same synchronization group could decide to delay its playout 
by two hours as well, in order to keep its playout synchronized. A 
user would likely interpret this two-hour delay as a malfunctioning 
service. 
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Therefore, the application logic of both SCs and MSASs should check 
for out-of-bound information. Differences in playout time exceeding 
configured limits (e.g., more than ten seconds) could be an 
indication of such out-of-bound information. 


Apart from checking for out-of-bound information in the endpoints, an 
IDMS implementation can reduce its vulnerability to attacks by 
including source authentication and message integrity measures, 
reducing the potential for man-in-the-middle attacks. [RFC7201] 
provides an overview of the security options in RTP environments and 
includes a set of recommendations for message integrity and source 
authentication that are applicable to IDMS. In addition to 
preventing man-in-the-middle attacks from inserting erroneous IDMS 
reports, the message confidentiality mechanisms outlined in [RFC7201] 
also prevent third parties from determining that two or more end 
hosts are receiving the same stream by looking at the Media Stream 
Correlation Identifier. 


Apart from attacking an IDMS session directly by sending incorrect 
IDMS reports, and with it introducing delays for all devices in a 
synchronization group, another potential vulnerability comes from the 
clock synchronization method used. Should an attacker succeed in 
adjusting an SC's wallclock, that SC will report incorrect IDMS 
reports. In order to prevent such clock synchronization attacks, it 
is recommended to use a secure time synchronization service. 


IANA Considerations 


This document defines a new RTCP packet type, the RTCP IDMS Packet 
(IDMS Settings), within the existing Internet Assigned Numbers 
Authority (IANA) registry of RTCP Control Packet Types. This 
document also defines a new RTCP XR Block Type, the RTCP XR IDMS 
Report Block, within the existing IANA registry of RTCP Extended 
Reports (RTCP XR) Block Types. 


Further, this document defines a new SDP attribute "rtcp-idms" within 
the existing IANA registry of SDP Parameters, which is part of the 
"att-field (media level only)". Finally, this document defines a new 
IANA registry subordinate to the IANA RTCP Extended Reports (RTCP XR) 
Block Type Registry: the IDMS XR Block SPST Registry. 


1. RTCP IDMS Packet Type 


This document assigns the packet type value 211 in the IANA 'RTCP 
Control Packet types (PT)' registry to the RTCP IDMS Packet (IDMS 
Settings). 
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.2. RTCP XR IDMS Report Block 


This document updates the assignment of value 12 from the RTCP XR 
Block Type for reporting IDMS information as per [TS183063] to the 
RTCP XR IDMS Report Block defined in this document. 

The RTCP XR IDMS Report Block contains an extensible SPST value 
field; therefore, a new registry for this field is required. This 
new registry is defined in Section 13.4. 


3. RTCP-IDMS SDP Attribute 


The SDP attribute "rtcp-idms" defined by this document is registered 
with the IANA registry of SDP Parameters as follows: 


SDP Attribute ("att-field"): 

Attribute name: rtcp-idms 

Long form: RTCP IDMS Parameters 

Type of name: att-field 

Type of attribute: media level 

Subject to charset: no 

Purpose: see Section 10 of this document 

Reference: this document 

Values: see this document 
4. IDMS XR Block SPST Registry 
This document defines a new IANA registry subordinate to the IANA 
RTCP Extended Reports (RTCP XR) Block Type Registry: the IDMS XR 
Block SPST Registry. 
Initial values for the IDMS XR Block SPST Registry are given below; 
future assignments are to be made through the Specification Required 
policy [RFC5226]. The registry is limited to 16 entries (numbered 
0-15), with 0 being Reserved. Values 5-15 are available for 
assignment. 
In accordance with [RFC5226], a Designated Expert will review any 


applications made to IANA for the registry. Primary criteria for the 
Designated Expert to use when reviewing new applications are clarity 
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of the specification and, due to the relatively small value range of 
SPST values available, potential overlap in functionality with 
existing SPST registrations. 


Value Name Reference 
1 Synchronization Client This document, Section 7 
2 MSAS [TS183063] 
3 SC Prime Input [79183063] 
4 SC Prime Output [79183063] 
13.5. Contact Information for Registrations 


The contact information for the registrations is: 


Ray van Brandenburg (ray.vanbrandenburg8tno.nl) 
Brassersplein 2 
2612CT, Delft, The Netherlands 
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